IBIS Macromodel Task Group Meeting date: 28 March 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy Siemens (Mentor Graphics): John Angulo * Arpad Muranyi SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Mike L. noted that Bob Ross had asked during the previous meeting whether BIRD 158.4 draft 2 was the latest revision. Mike said he had investigated and found that Radek emailed a later draft to the group on February 28th. This draft was mistakenly named BIRD_158.6.docx. Mike said he would post that version to the ATM work archives, and Bob R./Arpad/Mike L. decided it should be posted as BIRD158.4 draft 3. Arpad asked if this was the version to which he had replied with a long email regarding package modeling questions. It was. Mike L. took the AR to post the document as 158.4 draft 3. ------------- Review of ARs: - Walter and Radek to work on a draft 3 (now 4, see above) of BIRD 158.4. - In progress. - Walter send a draft 1 of his Reference_terminal proposal to Mike LaBonte for posting. - Done. - Bob Ross to email ATM with his concerns about the Reference_terminal proposal. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Michael M.: Motion to approve the minutes. - Mike L.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Interactions and Dependencies amongst BIRDs: - Arpad: BIRD 186.1, File Naming Rules, is scheduled for vote in the next Open Forum meeting. - Reviewing it, I noticed it has a forward-looking reference to something that is not in the spec yet. It contains a reference to "ims" files defined in BIRD 189. - Should we take that reference out of BIRD 186.1 and put it back in as part of BIRD 189? - Michael M: We could motion to delay the vote until BIRD 189 is approved. - Arpad: That is one option, but I thought people wanted BIRD 186.1 in first. - Bob R.: Yes, BIRD 147 was already approved and it contains a dependency on BIRD 186.1. - Arpad: Yes, if getting 186 approved is important then we should just trim the forward-looking stuff out of 186 so we can approve it quickly. - Michael M.: That might be too much work. - Arpad: I'm not certain, but I think the only thing that needs to be removed is the mention of the new "ims" file extension. - Bob R.: We could abandon any partial release and delay everything until BIRD 189 is approved and bring everything in at once. - Michael M.: I think the interest in having a 6.2 release has been waning. - The current question is what should go into 7.0 (backchannel, interconnect, etc.). - How much time do we want to put into the referencing and referencing cleanup in 7.0, or should we make that a separate effort in a 7.1? - Walter: I agree that momentum is toward not having a 6.2 release. - I think the only issues are whether BIRD 189 and the redriver flow BIRD go in 7.0. - I think BIRD 189 could be approved quickly. - I think BIRD 181.1 I-V Table Clarifications is editorial in the sense that EDA tools already interpret things properly. Clarifications won't affect the tools. If we can pull it into 7.0 great, but it's not necessary. - I don't care if my Reference_terminal BIRD gets included. I think it's useful for saying what we do if Reference_terminal isn't specified, but there are ongoing discussions about issues when no [*_Reference] keywords are zero. - Arpad: I would really like to see BIRD 189 in the next release of IBIS. - I don't think we should be considering any not-yet-written BIRDs in our planning for the next IBIS release(s). - Redriver flow has some urgency, but the BIRD is not ready. - Walter: The original redriver flow improvement BIRD I submitted makes sure the downstream Rx gets the right input to its Init() function. - Fangyi's BIRD is mine plus enhancements with additional inputs and outputs from Init(). - I don't need to get my redriver flow BIRD into the spec. We know the proper proper flow. - Arpad: It's dangerous as it stands. - One tool might follow the current flow in the spec (improper flow). - Another tool does it the "right way." - I'm leaning toward separating Walter's BIRD and Fangyi's proposal. - Fangyi thinks the two proposals are tightly interwoven. - Walter: His BIRD says take the Rx equalization and split out the effects of the CTLE and DFE into two separate impulse responses. - I think there are advantages to that, but I think the concept is independent of my proposal. - Arpad: Having a bad flow defined in the spec is an urgent problem. - Maybe we should set aside the bells and whistles and just get the basic flow correction. - Walter: I don't object to that. Reference_terminal proposal: - Walter: Motion to untable topic #10. [The Bob Ross and Radek referencing discussions, to which the Reference_terminal proposal is related.] - Michael M.: Second. [no objections] - Walter: [reviewing Reference_terminal proposal draft 2] - (see minutes from March 21 for a review of the draft 1 proposal and the discussed changes that went into draft 2). - Discussion: Arpad wanted to clarify and ensure that the Reference_terminal location is unique per buffer. Michael M. commented Reference_terminal is a subparameter of [Model]. But every instance of that [Model] has unique terminals. Arpad confirmed with an example: If you have a bedspring model for the ground plane of the chip, and you have 10 different buffers on that plane, each one of those buffer's reference terminals could be connected to different points on the ground plane model. Walter had noted that his proposal used the generally accepted names that we had adopted for the reference terminals (the naming convention from [Pin Mapping]). Bob R. noted that this was a point of discussion, and said that BIRD 189 had adopted capitalized versions of the names Walter used. Walter said this was an editorial issue we could resolve later. Bob R. noted that listing the mapping from Reference_terminal value to [External Model] port name was probably redundant. Walter agreed that it may be redundant with what's stated in [External Model], but he had restated it here for clarity. Bob R. noted that he had found the equation for the "Voltage at terminal" confusing. Walter stated that the point of the equation was to make it clear that a voltage was measured between the terminal and the Reference_terminal, and then the value (number, not a measurement) from the [* Reference] keyword corresponding to the Reference_terminal was added in as an offset. Arpad noted that he was uncomfortable with one of the rules for choosing the Reference_terminal when the Reference_terminal subparam hadn't been specified. He said that he was uneasy with the fact that all the terminals whose [* Reference] keywords had value 0.0 were to be considered "shorted together." Arpad said that it was possible for multiple terminals to have the same value at test time, but that it didn't mean that they weren't at different physical points at simulation time. Walter agreed that [GND Clamp Reference] and [Pulldown Reference] might both have value 0.0, but their planes might be connected in such a way that they had different values at simulation time. If that were the case, then the user should go ahead and select one of the two as the Reference_terminal. Arpad agreed with this, but asked why state the rule that the terminals were considered shorted. Bob R. noted that he thought this selection of the Reference_terminal was an expansion of what exists in IBIS currently. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Mike L. to post Radek's Feb 28th BIRD 158 draft as BIRD 158.4 draft 3. AR: Mike L. to post draft 2 of Walter's Reference_terminal proposal. ------------- Next meeting: 04 April 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives